Skip Headers

Oracle® OLAP Application Developer's Guide 10g Release 2 (10.2) Part Number B14349-02 |
Home | Book List | Contents | Index | Master Index | Feedback

Previous | Next
| View PDF

# 6 Administering Oracle OLAP

This chapter describes the various administrative tasks that are associated with Oracle OLAP. It contains the following topics:

- Administration Overview

- Creating Tablespaces for Analytic Workspaces

- Setting Up User Names

- Initialization Parameters for Oracle OLAP

- Initialization Parameters for OracleBI Beans

- Permitting Access to External Files

- Understanding Data Storage

- Monitoring Performance

## Administration Overview

Because Oracle OLAP is contained in the database and its resources are managed using the same tools, the management tasks of Oracle OLAP and the database converge. Nonetheless, a database administrator or applications developer needs to address management tasks in the specific context of Oracle OLAP, in addition to creating and maintaining analytic workspaces. Following is a list of these tasks.

- Tablespaces. Create permanent and temporary tablespaces to prevent I/O bottlenecks, as described in "Creating Tablespaces for Analytic Workspaces".

- Security. Users of OLAP applications must have database identities that have been granted the appropriate access rights. For users to have access to files, you must define directory objects and grant users access to them. Refer to "Setting Up User Names".

- Database configuration. Set initialization parameters to optimize performance, as described in "Initialization Parameters for Oracle OLAP" and "Initialization Parameters for OracleBI Beans".

- Performance. Database monitoring tools can identify recommended changes to the database configuration based on past usage, as described in "Monitoring Performance".

See Also: Oracle Database Administrator's Guide for detailed information about managing Oracle Database.

## Creating Tablespaces for Analytic Workspaces

Before you create an analytic workspace, you should create undo, permanent, and temporary tablespaces dedicated to their use. Analytic workspaces are created in the user's default tablespace, unless the user specifies otherwise. The default tablespace for all users is set initially to `SYS`. Creating analytic workspaces in the `SYS` tablespace can degrade overall performance. Similarly, analytic workspaces should not share tablespaces with relational tables, especially not the source schema.

Oracle OLAP makes heavy use of temporary tablespaces, so it is particularly important that they be set up correctly to prevent I/O bottlenecks.

If possible, you should stripe the data files and temporary files across as many controllers and drives as are available.

### Creating an UNDO Tablespace

The following SQL commands create an undo tablespace.

    CREATE UNDO TABLESPACE tablespace DATAFILE 'pathname'
         SIZE size REUSE AUTOEXTEND ON NEXT size
         MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;

Where:

tablespace is the name of the tablespace
pathname is the fully qualified file name
size is an appropriate number of bytes

For example:

    CREATE UNDO TABLESPACE olapundo DATAFILE '$ORACLE_HOME/oradata/undo.dbf'
        SIZE 64M REUSE AUTOEXTEND ON NEXT 8M
        MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL;

After creating the undo tablespace, change your system parameter file to include these settings, then restart the database as described in "Initialization Parameters for Oracle OLAP".

    UNDO_TABLESPACE=tablespace
    UNDO_MANAGEMENT=AUTO

### Creating a Permanent Tablespace for Analytic Workspaces

When a user creates an analytic workspace, it is created in the user's default tablespace, which is initially set to the `SYS` tablespace. The following SQL statements create a tablespace appropriate for storing analytic workspaces.

    CREATE TABLESPACE tablespace DATAFILE 'pathname'
        SIZE size REUSE AUTOEXTEND ON NEXT size MAXSIZE UNLIMITED
        EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

    ALTER USER username DEFAULT TABLESPACE tablespace

Where:

tablespace is the name of the tablespace
pathname is the fully qualified file name
size is an appropriate number of bytes
username is the name of a database user

For example:

    CREATE TABLESPACE glo DATAFILE '$ORACLE_HOME/oradata/glo.dbf'
       SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE UNLIMITED
       EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

If your computer has multiple disks, then you can stripe the tablespace across them. The next example shows SQL statements that distribute the `GLO` tablespace across three physical disks:

    CREATE TABLESPACE glo DATAFILE
       'disk1/oradata/glo1.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE 1024M
       EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

    ALTER TABLESPACE glo ADD DATAFILE
       'disk2/oradata/glo2.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE 1024M,
       'disk3/oradata/glo3.dbf' SIZE 64M REUSE AUTOEXTEND ON NEXT 8M MAXSIZE UNLIMITED;

### Creating a Temporary Tablespace for Analytic Workspaces

Oracle OLAP uses temporary tablespace to store all changes to the data in an analytic workspace, whether the changes are the result of a data load, what-if analysis, forecasting, aggregation, or some other analysis. An OLAP DML `UPDATE` command moves the changes into the permanent tablespace and clears the temporary tablespace.

Oracle OLAP also uses temporary tablespace to maintain different generations of an analytic workspace. This enables it to present a consistent view of the analytic workspace when one or more users are reading it while the contents are being updated. This usage creates numerous extensions within the tablespace, so be sure to specify a small `EXTENT MANAGEMENT` size.

The following commands create a temporary tablespace suitable for use by Oracle OLAP.

    CREATE TEMPORARY TABLESPACE tablespace TEMPFILE 'pathname'
       SIZE size REUSE AUTOEXTEND ON NEXT size MAXSIZE UNLIMITED
       EXTENT MANAGEMENT LOCAL UNIFORM SIZE size;

Where:

pathname is a fully qualified file name
size is an appropriate number of bytes
tablespace is the name of the tablespace
username is a database user

For example:

    CREATE TEMPORARY TABLESPACE glotmp TEMPFILE '$ORACLE_HOME/oradata/glotmp.tmp'
       SIZE 50M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED
       EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

You can stripe temporary tablespaces across several disks the same as permanent tablespaces. The next example shows the `GLOTMP` temporary tablespace striped across three physical disks.

    CREATE TEMPORARY TABLESPACE glotmp TEMPFILE
       'disk1/oradata/glotmp1.tmp' SIZE 50M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE 1024M
       EXTENT MANAGEMENT LOCAL UNIFORM SIZE 256K;

    ALTER TABLESPACE glotmp ADD TEMPFILE
       'disk2/oradata/glotmp2.tmp' SIZE 50M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE 1024M,
       'disk3/oradata/glotmp3.tmp' SIZE 50M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED;

### Querying the Size of an Analytic Workspace

To find out the size of the tablespace extensions for a particular analytic workspace, use the following SQL statements:

    COLUMN DBMS_LOB.GETLENGTH(AWLOB) HEADING "Bytes";
    SELECT EXTNUM, SUM(DBMS_LOB.GETLENGTH(AWLOB)) FROM AW$awname GROUP BY EXTNUM;

Where:

awname is the name of the analytic workspace.

## Setting Up User Names

To connect to the database, a user must present a user name and password that can be authenticated by database security. All users must have the `CONNECT` role. The additional privileges associated with that user name control the user's access to data. As a database administrator, you must set up user names with appropriate credentials for all users of Oracle OLAP applications.

You can define user names and grant them these rights from the Users General Page of Oracle Enterprise Manager Database Control or by using SQL commands.

Two roles are defined on installation of the database explicitly to support Oracle OLAP:

- `OLAP_USER` role provides users with the privileges to create, manage, or access standard form analytic workspaces. All OLAP users should have the `OLAP_USER` role or equivalent privileges.

- `OLAP_DBA` role provides a DBA or system administrator with privileges to create CWM metadata for relational tables. The `OLAP_DBA` role is granted with the DBA role.

See Also: Oracle Database SQL Reference for more information about granting privileges.

### SQL Access For DBAs and Application Developers

To use Analytic Workspace Manager, users must be granted the `OLAP_USER` role. They also need `SELECT` privileges on the source schema tables, and an unlimited quota on the tablespace in which the workspace is created. Example 6-1 shows the SQL statements for creating the `GLOBAL_AW` user.

Example 6-1 SQL Statements for Creating the GLOBAL_AW User

    CREATE USER 'GLOBAL_AW' IDENTIFIED BY 'global_aw'
       DEFAULT TABLESPACE glo
       TEMPORARY TABLESPACE glotmp
       QUOTA UNLIMITED ON glo
       ACCOUNT UNLOCK;

    GRANT SELECT ON global.channel_dim TO global_aw;
    GRANT SELECT ON global.customer_dim TO global_aw;
    GRANT SELECT ON global.product_dim TO global_aw;
    GRANT SELECT ON global.time_dim TO global_aw;
    GRANT SELECT ON global.price_and_cost_history_fact TO global_aw;
    GRANT SELECT ON global.price_and_cost_update_fact TO global_aw;
    GRANT SELECT ON global.units_history_fact TO global_aw;
    GRANT SELECT ON global.units_update_fact TO global_aw;

### SQL Access for Analysts

To access an existing analytic workspace, users must have these access privileges on the table in which the workspace is stored:

- To read from the analytic workspace, `SELECT` privileges.

- To write to the analytic workspace, `SELECT`, `INSERT`, and `UPDATE` privileges.

Note that the name of the table is the same as the name of the analytic workspace, with the addition of an `AW$` prefix. For example, the `GLOBAL` analytic workspace is stored in the `AW$GLOBAL` relational table.

For users to access views of workspace data, they must be granted `EXECUTE` privileges explicitly on those views.

Example 6-2 shows the SQL statements that gives all users read-only privileges to the `GLOBAL` analytic workspace, and user `SCOTT` read/write privileges.

Example 6-2 Granting Access Rights to the GLOBAL Analytic Workspace

    GRANT SELECT ON   global_aw.aw$global TO public;
    GRANT INSERT ON         global_aw.aw$global TO scott;
    GRANT UPDATE ON         global_aw.aw$global TO scott;

### Access to Database Objects Using OracleBI Beans

To connect to a database using OracleBI Beans, users must have the following access rights:

- `CONNECT` role

- `QUERY REWRITE` system privilege (for relational tables)

- `SELECT` privileges on the database objects containing the data to be analyzed, whether the data is stored in an analytic workspace or in relational tables. Refer to the previous topic, "SQL Access for Analysts", for information about granting access to analytic workspaces.

### Access to the Oracle JVM

Users who want to author or execute Analytic Workspace Java API applications within the Oracle Java Virtual Machine (JVM) may need the following Java permissions, in addition to the `OLAP_DBA` or `OLAP_USER` role:

Table 6-1 Java Permissions

Permission Type | Action
--- | ---
`java.io.FilePermission` | `read`, `write`, `execute`
`java.util.PropertyPermission` | `read`, `write`
`java.net.SocketPermission` | `connect`, `resolve`
`java.lang.RuntimePermission` | `null`

You can grant these permissions in either Java or SQL.

See Also: Oracle Database Java Developer's Guide for information about Oracle JVM security and Java permissions Oracle OLAP Analytic Workspace Java API Reference for information about using this Java API

## Initialization Parameters for Oracle OLAP

Table 6-2 identifies the parameters that affect the performance of Oracle OLAP. Alter your server parameter file or `init.ora` file to these values, then restart your database instance. You can monitor the effectiveness of these settings and adjust them as necessary.

These recommendations assume that the computer is dedicated to Oracle Database, and Oracle Database is used predominately (if not exclusively) for OLAP. If you want to reserve some resources for other applications, then first calculate the percent of resources that are available to Oracle Database. For example, if your computer has 4G of physical memory and you want to reserve 25% for other applications, then you would calculate `SGA_TARGET` and `PGA_AGGREGATE_TARGET` based on 75% of 4G, which is 3G.

Table 6-2 Initial Settings for Database Parameter Files

Parameter | Setting
--- | ---
`JOB_QUEUE_PROCESSES` | Number of CPUs, plus one additional process for every three CPUs For example, `JOB_QUEUE_PROCESSES=5` for a four-processor computer
`PGA_AGGREGATE_TARGET` | 25% of physical memory (increase up to 50% for builds and major query operations)
`SGA_TARGET` | 50% of physical memory
`SESSIONS` | 2.5 * maximum number of simultaneous OLAP users
`UTL_FILE_DIR` | Directory path where the Oracle Database can write to a file.
`UNDO_MANAGEMENT` | `AUTO`
`UNDO_TABLESPACE` | Name of the undo tablespace, which must be defined first as shown in "Creating an UNDO Tablespace"

See Also: Oracle Database Performance Tuning Guide for information about these parameters.

### Procedure: Setting System Parameters for OLAP

Take the following steps to set system parameters:

1. Open the `init``.ora` initialization file in a text editor.

2. Add or change the settings in the file.

   For example, you might enter a command like this so that Oracle can write files to the `olapscripts` directory:

   `utl_file_dir=c:\olapscripts`

3. Stop and restart the database, using commands such as the following. Be sure to identify the initialization file in the `STARTUP` command.

       SQLPLUS '/ AS SYSDBA'
       SHUTDOWN IMMEDIATE
       STARTUP pfile=$ORACLE_HOME/admin/rel10g/pfile/initrel10g.ora

### About the PGA_AGGREGATE_TARGET Setting

`PGA_AGGREGATE_TARGET` helps the OLAP engine determine whether the OLAP page pool can grow in response to a session's demand for pages. It is also used by SQL statements, particularly when performing `SELECT` statements with `GROUP BY` and `ORDER BY` clauses. `PGA_AGGREGATE_TARGET` can affect the performance of OracleBI Beans when selecting data from relational tables.

Set `PGA_AGGREGATE_TARGET` initially to 200-400MB, and use the database performance monitoring tools to recommend adjustments.

## Initialization Parameters for OracleBI Beans

OracleBI Beans performs best when the configuration parameters for the database are optimized for its use. During installation of Oracle Database, an OLAP configuration table is created and populated with `ALTER SESSION` commands that have been tested to optimize the performance of OracleBI Beans. Each time OracleBI Beans opens a session, it executes these `ALTER SESSION` commands.

If a database instance is being used only to support Java applications that use OracleBI Beans, then you can modify your server parameter file or `init.ora` file to include these settings. Alternatively, you might want to include some of the settings in the server parameter file and leave others in the table, depending upon how your database instance is going to be used. These are your choices:

- Keep all of the parameters in the configuration table, so that they are set as part of the initialization of a OracleBI Beans session. This method fully isolates these configuration settings solely for OracleBI Beans. (Default)

- Add some of the configuration parameters to the server parameter file or `init.ora` file, and delete those rows from the configuration table. This is useful if your database is being used by other applications that require the same settings.

- Add all of the configuration parameters to the server parameter file or `init.ora` file, and delete all rows from the configuration table. This is the most convenient if your database instance is being used only by OracleBI Beans.

Regardless of where these parameters are set, you should check the Oracle Technology Network for updated recommendations.

See Also: Oracle Database SQL Reference for descriptions of initialization parameters that can be set by the `ALTER SESSION` command

## Permitting Access to External Files

The OLAP DML contains three types of commands that read from and write to external files:

- File read commands that copy data from flat files to workspace objects.

- Import and export commands that copy workspace objects and their contents to files for transfer to another database instance.

- File input and output commands that read and execute DML commands from a file and redirect command output to a file.

These commands control access to files by using `BFILE` security. This database security mechanism creates a logical directory object to represent a physical disk directory. Permissions are assigned to the directory object, which control access to files within the associated physical directory.

You use PL/SQL statements to create a directory object and grant permissions. The relevant syntax of these SQL statements is provided in this chapter.

See Also: Oracle Database SQL Reference under the entries for `CREATE DIRECTORY` and `GRANT` for the full syntax and usage notes.

### Creating a Directory Object

To create a directory object, you must have `CREATE ANY DIRECTORY` system privileges.

Use a `CREATE DIRECTORY` statement to create a new directory, or a `REPLACE DIRECTORY` statement to redefine an existing directory, using the following PL/SQL syntax:

    {CREATE | REPLACE | CREATE OR REPLACE} DIRECTORY directory AS 'pathname';

Where:

directory is the name of the logical directory object
pathname is the physical directory path

### Granting Access Rights to a Directory Object

After you create a directory, grant users and groups access rights to the files contained in that directory, using the following PL/SQL syntax:

    GRANT permission ON DIRECTORY directory TO {user | role | PUBLIC};

Where:

permission is one of the following:

`READ` for read-only access
`WRITE` for write-only access
`ALL` for read and write access

directory is the name of the directory object

user is a database user

role is a database role

`PUBLIC` is all database users

### Example: Creating and Using a Directory Object

The following SQL commands create a directory object named `OLAPFILES` to control access to a physical directory named `/users/oracle/OraHome1/olap` and grant read access to all users.

    CREATE DIRECTORY olapfiles as '/users/oracle/OraHome1/olap';
    GRANT READ ON DIRECTORY olapfiles TO PUBLIC;

Users access files located in `/users/oracle/OraHome1/olap` with DML commands such as this one:

    IMPORT ALL FROM EIF FILE 'olapfiles/salesq2.eif' DATA DFNS

## Understanding Data Storage

Oracle OLAP multidimensional data is stored in analytic workspaces, which are, in turn, stored in relational tables. An analytic workspace can contain a variety of objects, such as dimensions, variables, and OLAP DML programs. These objects typically support a particular application or set of data.

Whenever an analytic workspace is created, modified, or accessed, the information is stored in a table in the relational database.

Important: These tables are vital for the operation of Oracle OLAP. Do not delete them or attempt to modify them directly without being fully aware of the consequences.

### Analytic Workspace Tables

Analytic workspaces are stored in tables in the Oracle Database. The names of these tables always begin with `AW$`.

For example, if the `GLOBAL_AW` user creates two analytic workspaces, one named `GLOBAL` and the other named `GLOBAL_PROGRAMS`, then these tables will be created in the `GLOBAL_AW` schema:

    AW$GLOBAL
    AW$GLOBAL_PROGRAMS

Tables are created by default with eight partitions. You can manage these partitions the same as you would for any other table in your database.

The tables store all of the object definitions and data. Each object in an analytic workspace is stored in one or more page spaces, and each page space is stored in a separate row of the table. A page space is grouping of related data pages; a page is a unit for swapping data in and out of memory.

For example, a dimension is stored in three page spaces and thus has three rows (one each for dimension members, a hash index, and a logical-to-physical map). A variable is stored in one row; a partitioned variable has a row for each partition.

Table 6-3 describes the columns of a table that stores an analytic workspace.

Table 6-3 Column Descriptions for Analytic Workspace Tables

Column | Data Type | NULL | Description
--- | --- | --- | ---
`EXTNUM` | `NUMBER(8)` | - | Extension number Analytic workspaces are stored in physical LOBs (called extensions), which have a default maximum size of 500MB. The first extension is 0, the second is 1, and so forth.
`PS#` | `NUMBER(10)` | - | Page space number Each object is stored in at least one page space.
`GEN#` | `NUMBER(10)` | - | Generation number A generation (a snapshot of the page space) is maintained for each reader to assure a consistent view of the analytic workspace throughout a session.
`AWLOB` | `BLOB` | - | Analytic workspace LOB Actual storage of the analytic workspace object.
`OBJNAME` | `VARCHAR2(60)` | - | Object name The name of the object in the analytic workspace.
`PARTNAME` | `VARCHAR2(60)` | - | Partition name A name for the page space in which the object is stored. Each object is stored in its own page space. A partitioned variable is stored with a page space for each partition. The number of partitions and their names are specified when a partition template is created in the analytic workspace.

Table 6-4 shows a few sample rows of an analytic workspace table, which are the results of the following query.

    SELECT ps#, gen#, objname, partname FROM aw$global WHERE
         OBJNAME = 'TIME' OR
         OBJNAME = 'UNITS_CUBE_UNITS_STORED'
         ORDER BY GEN#, PS#;

Table 6-4 Sample Rows From AW$GLOBAL

PS# | GEN# | OBJNAME | PARTNAME
--- | --- | --- | ---
`2515` | `0` | `TIME` | `TIME`
`2516` | `0` | `TIME` | `TIME`
`2517` | `0` | `TIME` | `TIME`
`2745` | `0` | `UNITS_CUBE_UNITS_STORED` | `UNITS_CUBE_UNITS_STORED`
`2515` | `2` | `TIME` | `TIME`
`2516` | `2` | `TIME` | `TIME`
`2517` | `2` | `TIME` | `TIME`

See Also: Oracle OLAP DML Reference for information about managing analytic workspaces.

### System Tables and Views

The `SYS` user owns several tables and views associated with analytic workspaces:

    AW$EXPRESS
    AW$AWMD
    AW$AWCREATE
    AW$AWCREATE10G
    AW$AWXML
    AW$
    PS$

Following are brief descriptions of these objects.

- `AW$EXPRESS` stores the `EXPRESS` analytic workspace. This workspace contains objects and programs that support the OLAP DML. The `EXPRESS` workspace is used any time that a session is open.

- `AW$AWCREATE` stores the `AWCREATE` analytic workspace, which contains programs for creating and managing standard form analytic workspaces for Analytic Workspace Manager 9.2.0.4.

- `AW$AWCREATE10G` stores the `AWCREATE10G` analytic workspace, which contains programs for using OLAP Catalog metadata in Analytic Workspace Manager 10.1.0.3.

- `AW$AWXML` stores the `AWXML` analytic workspace, which contains programs for creating and managing standard form analytic workspaces for Analytic Workspace Manager 10g.

- `AW$AWMD` stores the `AWMD` analytic workspace, which contains programs for creating standard form catalogs.

- `AW$` maintains a record of all analytic workspaces in the database, recording its name, owner, and other information.

- `PS$` maintains a history of all page spaces. A page space is an ordered series of bytes equivalent to a file. Oracle OLAP manages a cache of workspace pages. Pages are read from storage in a table and written into the cache in response to a query. The same page can be accessed by several sessions.

  The information stored in `PS$` enables the Oracle OLAP to discard pages that are no longer in use, and to maintain a consistent view of the data for all users, even when the workspace is being modified during their sessions. When changes to a workspace are saved, unused pages are purged and the corresponding rows are deleted from `PS$`.

- `ALL_AW_OBJ` is a view that lists the current objects in all analytic workspaces to which the user has access rights.

- `ALL_AW_PROP` is a view that lists the current OLAP DML properties and their values in all analytic workspaces to which the user has access rights.

The `CWM1` and `CWM2` read APIs are tables owned by the `OLAPSYS` user. Public synonyms provide user access to these tables.

## Monitoring Performance

Each Oracle Database instance maintains a set of virtual tables that record current database activity. These tables are called dynamic performance tables. The dynamic performance tables collect data on internal disk structures and memory structures. Among them are tables that collect data on Oracle OLAP. By monitoring these tables, you can detect usage trends and diagnose system bottlenecks. Refer to the Oracle OLAP Reference for information about the OLAP dynamic performance views.

## Copying and Backing Up Analytic Workspaces

You can copy analytic workspaces at several levels, either as a way of replicating it on another computer or backing it up.

- XML Template. A template saves the XML definition of logical objects in a standard form analytic workspace. You can save the entire analytic workspace, or individual cubes, dimensions, and calculated measures. Using a saved template, you can create a new analytic workspace exactly like an existing one. The template does not save any data, nor does it save any customizations to the analytic workspace. You can copy a template to a different platform.

- EIF File. An EIF file saves the object definitions of any analytic workspace (not just standard form analytic workspaces), and optionally, saves the data also. You can copy an EIF file to a different platform.

- Database Dump Files. Analytic workspaces are copied with the other objects in a schema or database export. You can use either the `expdp`/`impdb` or the `exp`/`imp` database utilities.

- Transportable Tablespaces. Analytic workspaces are copied with the other objects to a transportable tablespace. However, you can only transport the tablespace to the same platform (for example, from Linux to Linux, Solaris to Solaris, or Windows to Windows). You can use either the `expdp`/`impdp` or the `exp`/`imp` database utilities. Transportable tablespaces are much faster than dump files.

The owner of an analytic workspace can create an XML template or an EIF file, or export the schema to a dump file. Only users with the `EXP_FULL_DATABASE` privilege or a privileged user (such as `SYS` or a user with the `DBA` role) can export the full database or create a transportable tablespace.

See Also: Analytic Workspace Manager Help for information about exporting to an XML template or an EIF file. Search for the topic "Saving Analytic Workspaces in Flat Files." Oracle Database Utilities for information about Oracle Data Pump and the `expdp`/`impdp` commands.